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ABSTRACT 

In spite of the limitations of oinicomputorsi, Western 
Washington state College (WWSC) has developed a useful interactive 
computing system based on a Kodel 7/32 Interdata ainicpaputer and the 
computer program, PILOT. The major disadvantages of minicomputers are 
the difficulty of securing maintenance and the reliance o:£ten gn the 
single language, BASIC* Software systems are crucial and languages 
such as BASIC or APL are ill-suited for course-authori<ng :£or 
computer-assisted instruction (CAI).* cost, of course, is the 
principle advantage. The system at HWSC relies on a multilingual 
interpreter to execute programs in a constant pattern for all 
languages, once translated into an internal code of single byte 
operands and operators. PILOT has great structural simplicity but yet 
great versatility, aiid perhaps its best feature is its ability to 
call an already compil^ed BASIC subroutine/ A program vas written 
which can translate COURSEWRITEE III to PILOT. The experience gf WWSC 
indicates that a CAI system can be satisfactorily run pn a 
minicomputer if there is access to good software. (WH) 
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TluTo or. iwo .,oin thrusts l... this paper. The primary inttmt is to intro- 
duce you to tl^e mini- computer b.i^ed terminal system WWSC, as the title 
suggests. before I do that, however. 1 feel this is a good opportunity to 
co,-„r.eni on the role of the mini in interactive computing. Since our terminal 
system has been in the process of conversion from a 360/^^0 base to an Inter- 
data mini base over the past six mionths, we have some immediate experience 
to draw on for this discussion. 

First I would like to state categorically that minicomputers .re not the answer 
to all of our computing problems. !t is a mistake to think that a five- 
thousand dollar processor can do the job of a large-scale com.puter. Some 
of the problems associated with minicomputers are not unique to the mini. 
They can pertain to any computer equipment when a switch is made from estab- 
lished vendors, such as IBM, to a relative newcomer in the field of manufacturi 
Computer hardware, 

• ■ 

The response time when ma i n tenance i s needed has been a p rob 1 em, pa r 1 1 y due 
to Western's 'remote' location and partly due to the re 1 at i ve I y sma 1 I s i ^e of 
the Manufacturer's back-up organization. For Instance, we have had to sh,p 
parts of an Ann Arbor terminal to Michigan for repairs and replacement. Also 
the interface between one manufacturer's equipment and another's may not 
function toovvell, particularly i f you r i ns t a 1] a t ion i s a 'pioneer' . We spent 
four months working out hardware bugs in th^ interface between our Interdata 
and the ^SO/hO. On the other hand, the Ann Arbor and the Texas Instruments 
terminals were installed with nothing rixDre drastic than a minor plug change. 
Far and av/ay the most serious drawback to minis, however, is the lack of 
available software of any kind, but part i cularly software for CAI systems. ' 
There are few CAI systems available at all. and those that are available off • 
the shelf are primarily one-tanguage systems, usually BASIC. Many educational' 
installations do not want to limit their tcrninal systems to one language, 
as that imposes restrictions on the types of applications that can be mixed 
on the same system, i.e., CAI. interacllve programming, remote file mainten- 
ance, to name a few. tn addition, BASIC has never really established itself 
as an adequate CAI course authoring language. 
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Si' CO IMfM" ."iM.: no w?Orly j t ^''^J CAi svsLonis for roitiis, it i '.^ very dif~ 
tiv^ulu It not iii'.pos^-. i ul , fo' onv i ds t j I 1 u I I ut: rcj exchnnt^e courses with 
anolher. Tins is a slmiuh':. dfcrvvhock js you probcibly knov>, becctuse of the 
time andt affori required to develop rcolly good courseware. 

It is obvious thdt wlidl ib fK^oo*id is d software system that i compatible 
with many types of hijrdware and \s capable of handling at least two Ian- 
f^uages, one of wliich is a CAI author language, and the other an acceptable 
problem-solving language* We cannot stress enough our conviction that no 
one-language system is sufficient to meet the needs of course authors, even 
wnen no use other than CAI is made of an interactive system. Existing 
systems based on a computational language such as API or BASIC, in addition 
to being !l!-suited to course authoring, are too expensive of core for most 
users. The languages suited especially to course authoring are too re- 
strictive for the development of certain types of courseware. 

In spite of the potential problems of mini-based CAI systems, there is 
still ofie over r i di ng reason to try to make them go. That reason is the cost 
of hardv;are. Large mainframe systems that are widely accepted for CAI are 
beif^y abandoned by many users because they are too expensive to run. The 
choice is either to diminish the sii!e and capability of the interactive 
coiViQutlng system or to switch to less expensive equipment. For instance, 
at AA/SC it became clear* that CAI had to be done more cheaply or not al all; 
Our iiain comput^er had become overloaded v/ith batch v;ork and the prospects 
for upgrading it in the near future were not good. We found that a rather 
modest investment i n mi n i comput e r ha rdwa re v;ou 1 d give us enough power to 
run about sixteen student termi nal s. In fact, the cost of computer power 
for running between s i xteen and thr i tytwo terminals on such a system is about 
three- thousand dollars per terminal. This price does not include disk 
storage, which we already had. 1 t can cost anywhere from 10,000 to 20,000 
dol I ars to provi de disk storage for a system fol6 to 32 terminals, depending 
on the exact amount of disk space requ i red and the brand purchased. Neither 
does it include the cost of the termi na I s , wh i ch ranges anywhere from one 
thousand to three tfiousand dollars each* V 

The most sign! ficant advantage of a minicomputer based terminal system is 
that relatively lov/ cost can be obtained v/ithout going to a huge system. On 
the other hand , if many more termi nal s are needed one can readily expand by 
simply adding on duplicate syf^tems In grouos of up to say a maximum of 32^^^^^^^^^^^^^^^^:; 
terminals. 
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TluTi' jti: inhor(M'.t adv.ir uiqc^s U) such rielhot). The first, is that the 

built-in rL';iu.' = concy of ^v->rtMns reduces \ht^ posbibitity of catasirophic 
results u-nef) the ucca^iunol, but !novit<3ble, system crash occurs. Secondly, 
the smaller sy^teins can be dispersed so thai the processor 3nd the terminals 
are grouped close together. This not only reduces costly te I ecorrmun i cat ions 
links, but there is a great psychological advantagr for the user. It !s 
our experience that the further tie computer is from the terminal the more 
frustration is felt by the user when he has trouble v%/ith the system. An 
on-site computer installation gives the user someone to turn to when diffi- 
culties arise. The importance of having human communication between the 
remote user and th^ central installation cannot be emphasized too much. 

THE MULT 1 L i N GUAL I N TERPRETFR^ AT Jv|WS£ 

To turn now to a more specific look at the system we developed at WWSC , we 
have constructed a system based on a Model 7/32 Interdata minicomputer. This 
machine is capable of having a million bytes of core storage and has an 
instruction execution speed approximately equivalent to that of an IBM 
3bO/50. We will be connected through our 360/^40 to our main main disk system 
for storage of programs and data, but a disk could be attached directly to 
the system i f des I red. 

The system runs under the control of a time sharing monitor, This monitor, 
or operating system, handles all input/output to the terminals and to the 
dj':3k storage, whether it !s on-line or through the main computer. The aln- 
guage processor i tsel f Is based upon a general (or multilingual) interpreter. 
Tfiis interpreter is capable of executing programs that have been translated 
into an internal code made up of single byte operands and operators. Oper- 
ator routines are included to perform all func t ions that are needed to 
execute any of the languages in the system. Many of the languages share 
operator routines. For example, the sum of A + B is calculated by the same 
routine regardless of the language fo the original statement. In sum, the 
general interpreter i s the workhorse of the system. 

The programs that prepare v/ork for the interpreter are called front-end 
t rans I a tors , One front -end is provi ded for each high- level I anguage in the 
system, They convert the respective source statements into a standard 
interpretive code which can then be executed by the general Interpreter. 
When a program is to be run, it is written to a disk In soi.rce form. It Is 
then read from the disk, processed by the appropriate translator, and 



convLM t*/cj t.; : !}U^rprcl ] vr- o>d'.'. Al this poJrW., the prrHjCcM) can either be 
executtu by [ht: i nl r p rc i c r , <.>r ii can be wfitLen onto disk for later 
execution. ]hif, l<Hter upliv^n mejos thdt procirams that are to be run many 
C!nH>s can be saved in cofipilcd form and used over and over. This cuts 
dramatically the time required to execute programs, as they are executed 
i mmed i ate 1 y after beint^ read from storage. 

Our original terminal system, which was based on the 360/hO^ used a similar 
general interpreter capable of handling COURSEWRfTER III, BASIC and a 
locally written subset of PL/1 called WPl'. We are now moving to a system 
which combines, for the time being, BASIC, with which you are already 
familiar^ and PILOT, a course auttioring language which is relatively new. 

Our first introduction to PILOT came f rom a two-page article by Dr. Sylvan 

Rubin of the Stanford Research Institute published tn the November 1973 

2 

i,.sue of Computer Decisions, The article describes the language Itself and 
how it came into being. The beauty of PILOT !s that it has a very simple 
syntax and can be readily implemented on virtually any computer. At WWSC 
we have written our compiler for PILOT in tnterdata Assembler language. 
According to the art Ic 1 e , P I LOT compilers have been written in BASIC, FORTRAN, 
SNOBOL, APL, and PL/1 in addition to various machine-dependent assembler 
languages. All use the same user notation for the i nst ruction set , and a 
standard type of notation for local extens ions of the language. For the 
benefit of those among you who may not be familiar with PILOT, I v/ould like 
to describe the 1 anguage b r i ef I y . The fact that the entire language can be 
described in a two-page article says a great dea ! about the structural 
simpl icity of PILOT, but that is not to say that i t 1 acks versat i li ty . 

Only four op codes are required to begin coding a course in PILOT: T: for 
type text; A: for accept answer; M: for match answer; J: for jump or branch, 
tach of these op codes i s followed by a text field. In addition, any of 
these four op codes can be made conditional in one of two v-zays. Coding the 
letter lY' after an op code (for example, TY:) causes a statement to be 
executed only if the last answer to a match was successful. Conversely, 
appending the letter M^' to an op code causes a statement to be executed 
only if the previous match failed. A statement can also be made conditional 
on the value of an expression coded within parentheses after the op code 
(for example, A (max^mi n) : ) * Such expressions should be coded in BASIC no- 
tation. 

ItalciillliiiiiiilK 
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fouf ri>ort' .tun.rjri cdJ^^s for PILOT qro<*jtly enttance the I anguage . Tlie 
first throe are R: For rt^nork or comnienl ; U; for use subroutine; E: for 
end subroutine. Tlie fourtfi and nK)i, t powerful is. C: for compute. This op 
code is followed by either an expression or by a CALL to a subroutine. (At 
WWSC, BASIC notation and subroutines are used.) This feature allows all the 
computat ionol capabilities of BASIC to be embedded within a CAI course. 

Some other features of the language include the ova i 1 ab i 1 i ty of statement 
labels, identified by an initial asterisk (>'^) and placed irrmediately before 
an op code (e,g, . -VSTEP T:). The label can then be used in the text field 
of a J statement. Variable names preceded by a dollar sign (e.g. $NAME) 
can be coded in the text field of an accept answer statement. This will cause 
the student ^s answer to be stored in that variable. Such answers can be 
either numeric or alphabetic or mixed. The variable name can then be placed 
within the text of a T statement. When that variable name is reached by 
the program, the stored answer will print in its place, adding a personal 
touch to student-terminal interaction. 

There are other features of PILOT that greatly enhance programming ability. 
Without going into detail, there are statements for course segmentation and 
1 inkage; extended pattern matching with tolerance for common spe 1 I i ng errors; 
statements which allow line graphics within a CAl unit; the ability to con- 
trol a random access si ide projector. 

Perhaps the greatest advantage to the link between BASIC and PILOT at WWSC 
is the ability to CALL a 1 ready comp i led BASIC subrout i nes f rom a PILOT 
course. By el imi nat i ng the need for compiling a subprogram each time it is 
called, many CAI courses can be made ava i 1 abl e tha t are too costly in 
response t ime on systems which lack the compile feature. 

We believe that our system meets the followi ng needs . l) It is implemented 
on a relatively i nexpens i ve processor wi th no bu i I t- i n necess i ty for costly 
telecommunications charges, 2) It is versatile in that the user is not un- 
necessarily 1 imi ted i n his choice of high-level languages. A new language 
can be added to the sys tem wi t hout mod i f i ca t i on of ex I s t i ng sof twa re and even 
without significant service interruptions. 3) The general interpreter gives 
the system the advantages of a single language systen. k) It provides CAI 
authors with a language which is easy to learn. But authors who wish to do 
more sophisticated CAI programming are not bound by i t s s impl Ic i ty , since 
they have easy access to both the advanced features of the author language 
and to a problem-solving language. 



If is i ' •> ; ; J 1 1 ' I c; I \;f)v r v I Ui: f; f o\) 1 Ofi » of t r d n s ) o t i n existing c ou r s ewo re 
,vhen 0 shift tt5 d nev; LAI ijn"ju<iqc is made. In our siluaiion we solved the 
problem by wrliiny .\ pro^jrjn which translates COURSEWRITER tl! to PILOT. 
This took dpprox ink) t e 1 y 80 ~ 100 nion tiours of work. We estimate at the 
present time that we obtain about 30% con^plete conversion. That means, 
that S0% of the statements in a COURSEWRITER III course will be success ful 1 y 
converted without further human intervention. Some courses convert with no 
change whatsoever. The worst case so far was only (>0% successful. We are 
also aware of the existence of other translators to and from PILOT. 

CONCLUSIONS 

In summary, we feel that it is possible to run a CAI system on a minicomputer 
which is both cost effective and meets most of the needs of potential authors. 
On the other hand v/e feel that the probability of success Is directly re- 
lated to access to good software. Since many instaUations lack the human 
resources to develop their own software we recommend extreme caution before 
mak i ng a move to a mi n i -based system uiu 1 1 i t i s certain that sof twa re can 
be obtained which is adequate to meet the needs of the system users. 

We considered making some suggestions In the direction of establishing 
standards for CAI softv/are» but are discouraged by previous experience. The 
climate does not yet seem ripe for such a move. We are not attempting to 
push our own system as a standard, but are convinced that it is a step in 
the right direction and are willing to share it with anyone who is interested. 
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